1. Field of the Invention
The present invention relates to enterprise applications, and more specifically to developing enterprise applications using design patterns.
Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.
2. Background Art
Recently, an application architecture that is becoming widely used in the computing industry, specifically in an Internet environment, is the three-tier application architecture. The three tier architecture includes a database tier that includes a database server, an application tier that includes an application server and application logic (i.e., software application programs, functions, etc.), and a client tier. The application server responds to application requests received from the client, a request for a software applet for example. The application server forwards data requests to the database server.
An enterprise application is defined as an application used by a business for a business purpose. An enterprise's application (e.g., a scheduling, accounting or personnel application) may involve all three tiers as data that is used by the application maybe stored in a database. The computer software that enables execution of the enterprise application usually resides in the application tier. Developing this software has been a difficult task because there are no uniform standards which define the best way to approach a solution to a specific problem when working in the application tier. Before further discussing the problems associated with software development in the application tier, an overview of the three-tier computer architecture and an overview of the specific types of programming languages used in the application tier are provided.
Overview of the Three-Tier Architecture
FIG. 1 provides an overview of a three-tier architecture. Client tier 100 typically consists of a computer system that provides a graphic user interface (GUI) generated by a client 110, such as a browser or other user interface application. Conventional browsers include Internet Explorer and Netscape Navigator, among others. Client 110 generates a display from, for example, a specification of GUI elements (e.g., a file containing input, form, and text elements defined using the Hypertext Markup Language (HTML)) and/or from an applet (i.e., a program such as a program written using the Java™ programming language, or other platform independent programming language, that runs when it is loaded by the browser).
Further application functionality is provided by application logic managed by application server 120 in application tier 130. The apportionment of application functionality between client tier 100 and application tier 130 is dependent upon whether a “thin client” or “thick client” topology is desired. In a thin client topology, the client tier is limited in functionality, in that the end user's computer on the client tier is used primarily to display output and obtain input, while computing takes place in the application tier. A thick client topology, on the other hand, uses a more conventional general purpose computer having processing, memory, and data storage abilities. Database tier 140 contains the data that is accessed by the application logic in application tier 130. Database server 150 manages the data, its structure and the operations that can be performed on the data and/or its structure.
Application server 120 can include applications such as a corporation's scheduling, accounting, personnel and payroll applications, for example. Application server 120 manages requests for the applications that are stored therein. Application server 120 can also manage the storage and dissemination of production versions of enterprise application logic (i.e., the versions that are currently being used by the corporate users). Database server 140 manages the database(s) that manage data for applications. Database server 140 responds to requests to access the scheduling, accounting, personnel and payroll applications' data, for example.
Connection 160 is used to transmit enterprise data between client tier 100 and application tier 150, and may also be used to transfer the enterprise application logic to client tier 100. The client tier can communicate with the application tier via, for example, a Remote Method Invocator (RMI) application programming interface (API) available from Sun Microsystems™. The RMI API provides the ability to invoke methods, or software modules, that reside on another computer system Parameters are packaged and unpackaged for transmittal to and from the client tier. Connection 170 between application server 120 and database server 150 represents the transmission of requests for data and the responses to such requests from applications that reside in application server 120.
Elements of the client tier, application tier and database tier (e.g., client 110, application server 120, and database server 150) may execute within a single computer. However, in a typical system, elements of the client tier, application tier and database tier may execute within separate computers interconnected over a network such as a LAN (local area network) or WAN (wide area network). The application tier might also be divided into multiple other tiers, such as a web tier that generates presentation logic and accepts user responses from clients. The middle tier might also contain a business tier that handles the core business logic of an application and provides the necessary interfaces to the underlying business service components.
Platform Independent Programming Languages
A specific application for a three-tier computer architecture uses a platform independent programming language. One example of a platform independent programming language is the Java™ programming language developed by Sun Mcrosystems, however other platform independent programming languages exist as well and have similar application in a three-tier computing architecture.
One type of platform independent programming language comprises a collection of components. The components maybe implemented as one or more instances of object classes in accordance with known object-oriented programming practices, or the components may be implemented under one or more component model definitions. Several component model definitions are currently available, such as COM, CORBA, and javaBeans™.
Each component model provides for encapsulation of related functions and data structures into individual components, similar to what occurs under a standard object-oriented programming (OOP) approach. The particular mechanisms by which the components are managed and interact are defined according to the respective component model. Bridges may be constructed which allow components designed under different component model definitions to interact within a single application. Interaction is typically performed through a set of methods implemented by the component. These sets of methods are referred to as “interfaces” in some component models. The public methods by which OOP object classes interact are often presented in the form of application programming interface (API) definitions.
To provide a better understanding of encapsulation of related data structures and methods, an overview of object-oriented programming is provided below.
Object-Oriented Programming
Object-oriented programming is a method of creating computer programs by combining certain fundamental building blocks, and creating relationships among and between the building blocks. The building blocks in object-oriented programming systems are called “objects.” An object is a programming unit that groups together a data structure (one or more instance variables) and the operations (methods) that can use or affect that data. Thus, an object consists of data and one or more operations or procedures that can be performed on that data. The joining of data and operations into a unitary building block is called “encapsulation.”
An object can be instructed to perform one of its methods when it receives a “message.” A message is a command or instruction sent to the object to execute a certain method. A message consists of a method selection (e.g., method name) and a plurality of arguments. A message tells the receiving object what operations to perform.
One advantage of object-oriented programming is the way in which methods are invoked. When a message is sent to an object, it is not necessary for the message to instruct the object how to perform a certain method. It is only necessary to request that the object execute the method. This greatly simplifies program development.
Object-oriented programming languages are predominantly based on a “class” scheme. The class-based object-oriented programming scheme is generally described in Lieberman, “Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems,” OOPSLA 86 Proceedings, September 1986, pp. 214–223.
A class defines a type of object that typically includes both variables and methods for the class. An object class is used to create a particular instance of an object. An instance of an object class includes the variables and methods defined for the class. Multiple instances of the same class can be created from an object class. Each instance that is created from the object class is said to be of the same type or class.
To illustrate, an employee object class can include “name” and “salary” instance variables and a “set.sub.—salary” method. Instances of the employee object class can be created, or instantiated for each employee in an organization. Each object instance is said to be of type “employee.” Each employee object instance includes “name” and “salary” instance variables and the “set.sub.—salary” method. The values associated with the “name” and “salary” variables in each employee object instance contain the name and salary of an employee in the organization. A message can be sent to an employee's employee object instance to invoke the “set.sub.—salary” method to modify the employee's salary (i.e., the value associated with the “salary” variable in the employee's employee object).
A hierarchy of classes can be defined such that an object class definition has one or more subclasses. A subclass inherits its parent's (and grandparent's etc.) definition. The parent class is also referred to as a “superclass.” Each subclass in the hierarchy may add to or modify the behavior specified by its parent class. Some object-oriented programming languages support multiple inheritance where a subclass may inherit a class definition from more than one parent class. Other programming languages, such as the Java programming language, support only single inheritance, where a subclass is limited to inheriting the class definition of only one parent class. The Java programming language also provides a mechanism known as an “interface” which comprises a set of constant and abstract method declarations. An object class can implement the abstract methods defined in an interface.
An object is a generic term that is used in the object-oriented programming environment to refer to a module that contains related code and variables. A software application can be written using an object-oriented programming language whereby the program's functionality is implemented using objects. As previously discussed, the encapsulation provided by objects in an object-oriented programming environment maybe extended to the notion of components under a component model definition.
Implementation in a Programming Language Using Java Technology
An embodiment of the platform independent programming language that uses a three-tier computer architecture is implemented in the Java programming language. The Java programming language is an object-oriented programming language with each program comprising one or more object classes. Unlike many programming languages, in which a program is compiled into machine-dependent, executable program code, classes using Java technology are compiled into machine independent bytecode class files. Each class contains code and data in a platform-independent format called the class file format. The computer system acting as the execution vehicle supports the Java technology runtime environment. The runtime environment contains a program called a virtual machine, which is responsible for executing the code in classes.
Applications maybe designed as standalone Java technology applications, or as “applets” which are identified by an applet tag in an HTML document, and loaded by a browser application. The class files associated with an application or applet may be stored on the local computing system, or on a server accessible over a network Each class is loaded into the Java technology runtime environment, as needed, by the “class loader.”
Java technology classes are loaded on demand from the network (stored on a server), or from a local file system, when first referenced during an application or applet's execution. The runtime environment locates and loads each class file, parses the class file format, allocates memory for the class's various components, and links the class with other already loaded classes. This process makes the code in the class readily executable by the virtual machine.
Java technology classes may also be incorporated into Java technology components referred to as “JavaBeans”. Javabeans are designed in accordance with the JavaBean API Specification to allow for component-based application building. Bridges may be used with JavaBeans to allow Javabeans to be used in other component model environments, such as OLE/COM and CORBA.
The Java technology example partitions the work needed to implement a multi-tier service into two parts: the business and presentation logic to be implemented by the developer, and the standard system services provided by the Java technology platform. This partitioning is shown in FIG. 3. The developer can rely on the platform to provide the solutions for the systems level problems associated with developing a middle-tier service. In addition, the three-tier model avoids the drawback of having to download the application logic to each user's client computer.
Unfortunately, in the development of three-tier applications, the development of the client software, particularly in the middle layer, is left without formal guidelines. Without formal guidelines, one current scheme for developing application software in the middle tier is for the developer to consult with the client to define the problem Once the problem is defined, the developer generates a computer program configured to execute in the middle tier (e.g., an enterprise application). Then, when the next client consults with the developer, the process repeats. Thus, each time a client has a problem, the solution is generated in an ad hoc and non-uniform fashion.
Using this scheme, often a developer would solve a customer's problem in one case, and another developer would have to re-create the same solution for a different customer who had the same problem. Without a way to obtain specific and provenly effective solutions that have particular use, software development in a multi-tier environment was disadvantaged.